IBIS Macromodel Task Group

Meeting date: 21 May 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:                Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai                             
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):           Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Teraspeed Labs:               [Bob Ross]
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Arpad noted that a recent device vendor inquiry about support for MIPI C-PHY
  modeling had prompted private discussions about renewed interest in:
  - C-PHY
  - [Ramp] (T-coils)
  - multi-level stimulus for [External Model] and [External Circuit]
  
-------------
Review of ARs:

Michael:  Send revised BIRD 230 to Open Forum.
          - Done.  It was submitted as BIRD 230.1.
          
Michael:  Prepare a list of BIRDs for the next IBIS version and share it with
          the Open Forum.
          - Done.  Michael reported that this had been discussed at the most
            recent Open Forum meeting.  Michael said one question is whether to
            call the next version IBIS 8.0 (as opposed to 7.3).  He noted that
            all BIRDs introduced since IBIS 7.2, with the exception of BIRD220,
            are either already approved or expected to be approved soon.  If the
            Open Forum agrees then the Editorial task group could begin work on
            the next version of IBIS soon.
            
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 30th
meeting.  Curtis moved to approve the minutes.  Michael seconded the motion.
There were no objections.

--------------
New Discussion:

Fixing [Clock Pins]:
Michael said he had not received any new feedback on his proposal.  He said he
has a minor clarification BIRD proposal that could resolve the current short-
comings with respect to DDR Controllers.  However, he doesn't want to propose
that change until he is sure it won't overly constrain us in the future.

Michael said he would like feedback from people on what types of timing
relationships, particularly with respect to memory, should be included in this
keyword.  He said many EDA tools have wizards that need timing information to be
provided by the user.  Could it be specified in an IBIS model, and if so, what 
form should it take?  The [Clock Pins] keyword has some provisions for providing
this information, but we need to avoid hard coded numbers that limit our ability
to support devices with varying capabilities.

Arpad elaborated based on some private discussions with Michael.  He said that
his organization, for example, uses a Verilog based .v file to provide this
timing information.  He said Michael had reported that different EDA tools seem
to have their own formats for providing timing information.  Should we develop a
standardized way to pass this information in an IBIS-like format along with the
IBIS models, so it's portable between vendor platforms, or are we happy with
everyone doing things their own way?  Michael said his organization would prefer
not to have to provide timing information in 4 or 5 different formats depending
upon the EDA tool their customer preferred.

Michael said that if fixing the known shortcoming with respect to controllers
is the only issue, then he has a straightforward fix for [Clock Pins].  It would
use the relationship column to introduce clock "groups" analogous to [Model
Selector], which would allow different clock pin to data pin relationship
groupings to be selected.  However, we may not want to adopt this change if it
will give up flexibility that we might need later.  Do we want to be able to
specify actual timing relationships and timing information?  How could we set up
selectors that support different speeds and timing specifications, not just
different clock-data pairings?

Randy said that the last time we put something in the IBIS specification that
was tied to a standard was the [Receiver Thresholds] keyword added in the DDR2|3
timeframe.  He said the issue that arose was that threshold levels were specific
to a data rate.  You might have one IBIS [Model] that covered a bunch of data
rates, but if you wanted to include Rx thresholds for every data rate you had to
duplicate the [Model] over and over just to provide a different set of
thresholds in each.  He agreed with Michael that we need something more flexible
than hardcoding information into a [Model] keyword.

Arpad asked whether the content of the timing file should be standardized, or
whether we should support everybody's different formats?  Michael said that
supporting multiple formats would get us into the same morass we ran into with
multi-lingual models.  If you make it too flexible, then no one uses it.
Michael said he would prefer one standard format that would work in any tool.

Michael suggested that one path forward would be to ask whether major EDA
vendors would be willing to send examples of the formats they currently use
for timing information.  If we could get a sampling of existing EDA tool
formats, and information about the kinds of data system designers think they
need and device vendors are willing to provide, it would be helpful in coming
up with  a standardized format.  Arpad said he thought his organization could
provide some file format examples.  Ambrish and others said they would check
with the respective experts in their organizations.

BIRD220 update:
Randy reported that this was discussed at the last Open Forum meeting.  He said
Chulsoon had indicated that his team is investing further.  They expect to bring
something back to ATM, possibly in June.

MIPI C-PHY:
Arpad said a recent post to the ibis-users list from a MIPI C-PHY vendor had
started discussions about C-PHY support in IBIS.  He said that in his experience
C-PHY is a unique and unusual standard, and it would be a major undertaking to
generate a syntax to support it within IBIS.  He asked whether anyone had any
insight into whether it would be worth the effort.

Randy said that he'd seen an increasing number of people using C-PHY, and he
and Wei-hsing noted several past IBIS Summit presentations on the topic.
Michael reported that people had approached him at DesignCon and asked when IBIS
would be able to support C-PHY.

Ambrish said it's a fundamentally different technology.  It's a 3-wire system,
and it is almost as though it defines the way the stimulus would be presented.
It's really outside of IBIS and at a higher level of the stack.  Unless we want
to get into encoding, etc., he wasn't sure this was a topic for IBIS.  He asked
whether anyone with experience might present an introduction.

Arpad said he could prepare an introductory presentation based on his past
experience with C-PHY.  He agreed that it's a major undertaking, and we'd first
have to decide that we think it's worth the effort.  The group agreed that we
need to do some background work to confirm the industry need for IBIS support of
C-PHY, make sure it's still a hot topic, etc.

Wei-hsing noted a presentation from the November 2020 China IBIS Summit that
described C-PHY modeling with multiple conventional IBIS buffers.  He asked
whether Arpad was envisioning incorporating 3 states into a conventional
IBIS [Model].  Arpad said that C-PHY Tx signals are basically PAM3, with a high,
middle, and low level.  He said the IBIS [Model] doesn't natively support that,
but he had created a PAM3 implementation usings [Submodel]s, though in a non-
compliant way.  He said the easiest way to support PAM3 in IBIS might be along
those lines, and then we would also need support for a 3-level stimulus.

Arpad and Randy noted additional complications with C-PHY including the fact
that it uses 3 single-ended buffers (a triplet) on the Tx side and measures
differentially across the 3 wires with 3 Rx buffers.  Arpad said it has a
rigorously defined state machine that only allows certain combinations of states
between the 3 levels on each of the 3 lines.  Should IBIS get involved with
this or just expect the EDA tool to handle the CPHY Tx states properly?  Ambrish
asked why IBIS would get involved with any of this if the MIPI specification
does it already.  Perhaps we should just worry about defining terminations so
that we can have 3 different IBIS [Models] for the individual Txs, a three-level
curve coming out of each Tx, and the proper Rx terminations.  Aside from that,
we should leave the rest to the MIPI specification.  Randy agreed that our
concern is really about adding support for defining the buffers themselves in a
compliant way.

Arpad noted that he had previously presented a multi-level IBIS analog buffer
modeling proposal.  He said he had worked on a BIRD draft, but it was not ready
yet, and there had not been much interest.  He said if we want to support C-PHY
with regular I-V and V-T tables, then we would probably need his BIRD.

Arpad asked whether this topic is something we should consider in the AMI
sections of the specification, or should it be in the I-V and V-T analog
sections?  Ambrish said the I-V and V-T information is needed for the channel
characterization even if we handle C-PHY with AMI.  Arpad said that for AMI we
just need one overall IR derived using the maximum swing from the Tx.  Once we
have that, the levels from the Tx in a PAMn AMI scenario are handled by using
equally spaced levels in the input stimulus waveform to the Tx.  If we were to
try to support multi-level signaling in the I-V and V-T tables, then we would
likely need additional sets of I-V data and also different V-T curves for each
of the transitions amongst the various levels.  It's not particularly
challenging to do, but the model would get much bigger.

Wei-hsing and Ambrish noted that CTLE and FFE are also defined in C-PHY, so we
might need to use AMI.  Arpad countered that the FFE in C-PHY is currently
similar to the old pre-emphasis and de-emphasis cases IBIS handled with [Driver
Schedule].  If the C-PHY FFE were ever to be extended to additional taps, then
this approach might not be practical, however.  Arpad said CTLE could also be
handled without AMI, perhaps with an S-parameter model, for example.  So, we
aren't necessarily forced into the AMI domain to handle C-PHY.  Ambrish noted
that if anything utilizes DFE then we would need AMI type modeling.

Arpad said that he had seen several presentations on CORD signaling.  He said
that C-PHY could be considered a subset of CORD signaling, and he wondered
whether we would want to consider a more general support for CORD signaling if
we look into C-PHY support.  Arpad asked everyone to think about these topics
and investigate further.

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

None.

-------------
Next meeting: 28 May 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
